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FOREWORD 


This  volume  is  one  of  nine  individually  bound  volumes  that  constitute 
the  Phase  II  Final  Report  "Study  of  Embedded  Computer  Systems  Support" 
for  Contract  F33600-79-C -0540.  The  efforts  and  analyses  reported  in 
these  volumes  were  sponsored  by  AFLC/LOEC  and  cover  a  reporting 
period  from  September  1979  through  September  1980. 

The  nine  volumes  are 
V  olume  Title 

I  Executive  Overview  (CDRL  05) 

II  Selected  ECS  Support  Issues:  Recommendations/ 
Alternatives  (CDRL  02A) 

III  Requirements  Baseline:  Aircrew  Training 
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IV  Requirements  Baseline:  Automatic  Test 

Equipment  (CDRL  02A) 

V  Requirements  Baseline:  Communications- 

Electronics  (CDRL  02A) 

VI  Requirements  Baseline:  Electronic  Warfare 

(CDRL  02A) 

VII  Requirements  Baseline:  Operational  Flight 
Programs  (CDRL  02A) 

VIII  ECS  Technology  Forecast  (CDRL  03) 

IX  National  Software  Works  Investigation 
(CDRL  04) 
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1.  INTRODUCTION 


Support  of  Embedded  Computer  Systems  (ECS)  in  the  1980's  presents 
a  major  challenge  to  the  Air  Force  Logistics  Command  (AFLC).  Major 
new  systems  in  the  active  force  inventory  and  those  currently  in  develop¬ 
ment  make  extensive  use  of  digital  technology.  In  addition,  existing 
weapon  systems  are  being  modified  to  incorporate  digital  technology. 
Several  of  these  systems  containing  embedded  computers  have  been 
deployed  and  problems  associated  with  their  support  surfaced  in  the  early 
1970's.  Many  of  these  problems,  particularly  the  support  of  computer 
programs,  can  be  attributed  to  past  acquisition  practices  as  well  as  a 
major  shift  in  support  philosophy  that  also  occurred  in  the  early  1970's. 
This  shift  towards  increased  government  support  was  designed  to 
increase  government  control  to  provide  improved  mission  responsiveness. 

The  Logistics  Command  responded  to  this  transition  to  the  digital 
operational  and  support  environment  with  new  and  innovative  support 
approaches  and  new  facilities  and  trained  personnel  to  ensure  that 
adequate  support  was  provided  for  fielded  combat  units.  Concurrent 
with  the  Air  Force  and  the  Department  of  Defense  development  of  policy 
and  guidelines  for  ECS  support,  AFLC  initiated  activities  on  a  case-by¬ 
case  basis  to  establish  software  support  facilities  at  the  various  Air 
Logistics  Centers. 

While  these  early  efforts  were  primarily  focused  on  support 
facilities  for  aircraft  related  operational  flight  programs,  AFLC  was 
also  involved  in  a  broad  range  of  activities  for  support  of  other  embedded 
computer  systems.  One  of  these  early  efforts  was  Air  Force  Project 
Pacer  Flash.  The  Pacer  Flash  group  looked  at  three  categories  of  soft¬ 
ware  support:  (1)  Operational  Flight  Programs  (OFP),  (2)  Automatic 
Test  Equipment  (ATE),  and  (3)  Aircrew  Training  Devices  (ATD).  Two 
other  categories  were  added  later:  Electronic  Warfare  (EW)  and 
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Communications-Electronics  (C-E).  Other  efforts  included  involvement 
in  the  development  of  AFR  800-14  Volume  I  and  II  and  DODD  5000.29. 

In  addition,  AFLC  took  an  early  lead  in  the  development  of  Computer 
Resource  Integrated  Support  Plans  (CRISP)  and  Operational  Support  Con¬ 
figuration  Management  Procedures  (O/S  CMP).  Based  on  this  early 
involvement  and  experience  and  a  continuing  requirement  to  improve 
and  refine  support  systems  effectiveness  and  reduce  support  costs  for 
an  ever  increasing  number  of  systems,  AFLC  is  seeking  additional  new 
support  initiatives. 

Accordingly,  several  complementary  efforts  are  in  progress  in 
response  to  this  requirement  for  management  and  technical  focus  on  the 
support  of  embedded  computer  systems.  For  example,  (1)  a  recently 
published  AFLC  Regulation  (AFLCR  800-21)  implements  the  policies  of 
AFR  800-14  and  other  related  directives  in  the  support  of  defense  systems, 
(2)  effort  is  underway  to  project  and  define  support  requirements  through 
development  of  a  "Statement  of  Need,  "  (3)  a  joint  AFLC-AFSC  effort 
has  been  initiated  to  investigate  and  demonstrate  the  utility  of  the 
National  Software  Works  to  maintain  software  systems  within  AFLC, 
and  (4)  an  AFLC  Computer  Resource  Review  Group  (CRRG)  was  recently 
established  to  coordinate  command  policy  and  delineate  responsibilities. 

In  addition  to  these  in-house  activities,  AFLC  initiated  this  contractor 
study  of  Embedded  Computer  Systems  Support. 

1.1  ECS  SUPPORT  STUDY  DEFINITIONS 

Computer  resources  consist  of  the  totality  of  computer  equipment, 
computer  programs,  computer  data,  associated  computer  documentation, 
contractual  services,  personnel,  and  computer  supplies. 

The  pervasiveness  of  digital  applications  in  individual  weapon 
systems  and  in  the  aggregate  makes  it  difficult  to  separate  precisely 
or  place  the  various  weapon  systems  in  categories  or  to  define  the 
various  categories  of  embedded  computer  systems.  Figure  1-1  sum¬ 
marizes  the  definitions  of  categories  of  ECS  support  assumed  for  purposes 
of  this  study. 
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Syatema  Defimti 


The  key  attributes  of  an  embedded  computer  system  are 


•  It  is  a  computer  system  that  is  physically  incorporated 
into  a  larger  system  whose  primary  function  is  not 
data  processing. 

•  It  is  integral  to  such  a  larger  system  from  a  design, 
procurement,  or  operations  viewpoint. 

•  Its  outputs  generally  include  display  data,  computer 
control  signals,  and  computer  data. 

1.2  OBJECTIVES  AND  SCOPE  OF  THE  STUDY 

The  purpose  of  this  study  is  to  develop  a  long  range  plan  for  use  by 
HQ  AFLC  to  manage  and  maintain  Embedded  Computer  Systems  on  a 
command-wide  basis  in  the  1980's.  The  study  effort  was  initiated  on 
28  September  1979  and  is  divided  into  three  phases  as  shown  in  Figure 
1-2,  with  the  following  specific  tasks  to  be  accomplished  over  a  period 
of  17  months. 

•  Develop  a  program  plan  which  describes  the  study 
approach,  procedures  and  schedules  (Phase  I:  Approved 
19  November  1979). 

•  Establish  a  baseline  for  current  ECS  support  functions 
and  requirements  (Phase  I  and  E). 

•  Assess  and  forecast  major  technology  impacts  on 
future  systems  and  their  attendant  support  require¬ 
ments  (Phase  II). 

•  Investigate  the  potential  use  of  networking  and  the 
National  Software  Works  (NSW)  and  other  support 
concepts  (Phase  II). 

•  Develop  a  long  range  plan  with  accompanying  method¬ 
ology  and  implementation  procedure  for  improving  the 
AFLC  Embedded  Computer  System  Support  posture 
for  the  1980's  (Phase  HI). 

1.3  PHASE  E  FINAL  REPORT 

During  the  past  year,  several  closely  related  reports  were  written. 
This  Phase  II  final  Report,  which  constitutes  the  contract  deliverables, 
contains  the  work  completed  through  September  1980.  This  report  con¬ 
sists  of  nine  volumes  as  shown  in  Figure  1-3. 
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Figure  1-2.  Study  Activity  and  Flow 
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1.3.1  Volume  I:  Executive  Overview 


This  volume  provides  background  information,  describes  the  contents 
of  the  report  and  discusses  the  study  methodology  employed  during  the 
study.  It  also  summarizes  the  major  study  findings.  An  outline  of  the 
long  range  plan  which  is  to  be  developed  during  Phase  III  of  the  study  is 
also  included  with  this  volume  as  Section  3. 

1.3.2  Volume  II:  Selected  ECS  Support  Issues,  Recommendations/ 
Alternatives 


This  volume  contains  a  discussion  and  analysis  of  selected  ECS 
support  issues  related  to  the  current  ECS  support  posture.  It  summarizes 
these  issues  and  separates  them  into  administrative/programmatic 
recommendations /alternatives. 

1.3.3  Volumes  IH-VII:  Requirements  Baseline 

These  five  volumes  contain  the  requirements  baselines  and  current 
support  posture  assessments  for  the  individual  ECS  categories.  Each 
of  the  volumes  is  structured  generally  as  follows: 

•  ECS  Category  Description 

A  description  of  the  particular  ECS  category  and  the 
mission  functions  that  it  performs. 

•  ECS  Support  Requirements 

A  discussion  of  the  common  ECS  support  requirements 
as  they  relate  to  the  particular  category  and  identification 
of  ECS  support  requirements  unique  or  peculiar  to  the 
category. 

•  ECS  Support  Concept 

A  description  of  the  support  concept  designated  for  the 
particular  ECS  category  and  a  discussion  of  the  facility 
elements  and  concept  as  implemented  at  the  various  Air 
Logistics  Centers. 

•  Representative  ECS  Systems 

This  section  examines  in  detail  selected  ECS  support  systems 
within  the  particular  category  to  enable  an  assessment  of  the 
effectiveness  of  the  subject  support  system  as  well  as  the 
current  posture  for  the  ECS  category. 

e  Assessment  of  Current  ECS  Support  Posture 

This  section  summarizes  the  current  support  posture  for 
the  category. 
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1.3.4  Volume  VIII:  ECS  Technology  Forecast 

This  volume  contains  an  identification  of  key  trends  related  to 
computer  resources  and  an  analysis  of  major  technologies  and  forecasts 
their  anticipated  impact  on  the  support  of  ECS  by  1990. 

1.3.5  Volume  IX:  National  Software  Works  Investigation 

This  volume  contains  an  assessment  of  the  potential  applicability  of 
the  National  Software  Works  to  the  ECS  support  mission.  It  focuses  on 
the  capabilities  currently  available  and  their  applicability  for  the  use  in 
the  near-term  support  of  ECS  common  and  unique  support  requirements. 
Networking  as  it  applies  to  ECS  support  needs  is  also  addressed. 

1.4  ECS  STUDY  METHODOLOGY 

The  study  methodology  employed  during  the  past  12  months  for 
Task  2  (requirements  baselines)  was  designed  to  systematically  generate 
data  to  support  a  sequential  and  iterative  analysis  of  support  requirements, 
activities,  support  concepts,  and  alternatives  for  each  of  the  five  ECS 
categories.  Data  collection  and  analysis,  which  was  a  major  activity 
for  each  ECS  category,  included  a  review  of  existing  and  planned 
weapon  and  support  system  documentation  provided  by  AFLC  and  by 
visits  to  HQ  AFLC  and  each  of  the  Air  Logistics  Centers  for  briefings 
and  interviews  with  management  and  engineering  personnel.  The  effort 
was  conducted  to  acquire  or  verify  sufficient  weapon  and  support  system 
data  to  facilitate  analysis  and  documentation  of  ECS  support  requirements 
and  concepts  for  a  more  in-depth  analysis  of  a  limited  number  of  repre¬ 
sentative  weapon  and  support  systems  within  each  ECS  category. 

Support  requirements  were  also  examined  to  determine  requirements 
common  to  all  five  ECS  categories  and  those  which  are  unique  or  peculiar 
to  a  particular  ECS  category.  Each  ECS  category  report  discusses  the 
Common  ECS  support  requirements,  which  are  described  as  a  generic 
process,  and  the  unique  requirements  for  that  category.  These  require¬ 
ments  formed  the  baseline  requirements  as  well  as  the  basis  for  deter¬ 
mining  if,  or  to  what  degree,  the  support  concept  as  currently  identified 


and  implemented  was  effective  in  providing  support  for  the  category. 
Assessments  were  made  based  upon  analysis  of  a  limited  number  of  weapon 
and  support  systems  chosen  from  each  ECS  category.  Consequently, 
these  assessments  and  the  overall  posture  assessments  for  each  category 
are  "snapshots”  of  the  current  support  posture,  rather  than  an  in-depth 
examination  of  every  facet  of  ECS  support. 

The  study  methodology  for  the  other  Phase  I  and  II  tasks,  i.  e. , 

Task  3  (technology  forecast)  ,  Task  4  (NSW  investigation)  and  Task  5 
(long  range  plan  annotated  outline)  was  tailored  to  the  specific  task. 

The  technology  forecast,  for  example,  was  accomplished  by  forming  a 
Technology  Working  Group  of  senior  engineers  and  scientists  with 
expertise  in  the  technology  areas  pertinent  to  the  AFLC  ECS  support 
role.  The  NSW  applicability  assessment,  on  the  other  hand,  was 
accomplished  primarily  by  a  senior  principal  investigator,  with  close 
coordination  and  review  by  personnel  experienced  in  networking  and 
actual  performance  in  a  variety  of  NSW  related  contractual  tasks  for 
Rome  Air  Development  Center.  A  working  groupwas  also  formed  to 
further  examine  ECS  support  problems  and  issues  that  surfaced  during 
the  baseline  investigations.  This  group  called  the  Operations  and  Support 
Working  Group,  consisted  primarily  of  TRW  field  site  managers  and 
other  engineers  and  scientists  collocated  with  AFLC  engineering  divisions 
at  various  Air  Logistics  Centers.  This  group  wrote  a  series  of  "white 
papers"  on  selected  topics  which  were  identified  and  coordinated  as 
major  problems  and  issues  in  the  support  of  ECS.  In  the  preparation 
of  the  long  range  plan  outline,  another  approach  was  used.  This  activity 
was  infused  with  close  coordination  with  TRW  management  personnel, 
members  of  the  ECS  study  team,  and  extensive  interaction  with  HQ  AFLC 
management  and  technical  personnel.  The  overall  study  approach  used 
in  Phase  II  is  shown  in  Figure  1-4. 
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AIR  FORCE  ECS  COMMUNITY 


Figure  1-4.  Phase  II  Study  Approach 


2.  PHASE  II  SUMMARY  OF  ECS  STUDY  MAJOR  FINDINGS 


This  section  contains  a  summary  of  the  conclusions  and 
recommendations  detailed  in  the  separate  volumes  of  the  Phase  II  final 
report.  Many  of  the  problem  areas  affect  all  of  the  ECS  categories  or 
are  otherwise  interrelated;  therefore,  only  the  major  study  findings 
are  included  in  this  overview.  This  section  is  presented  in  four  parts: 
selected  ECS  support  issues,  requirements  baselines,  ECS  technology 
forecast,  and  National  Software  Works  investigation.  These  subsections 
correlate  with  the  individual  volumes  of  the  Phase  II  report  as  shown 
in  Table  2-1.  Each  subsection  contains  a  brief  introductory  discussion 
followed  by  major  recommendations  and  alternatives  as  applicable. 

2.1  SELECTED  ECS  SUPPORT  ISSUES 

The  requirement  to  provide  support  for  embedded  computer 
resources  is  significantly  different  from  the  traditional  role  of  buying, 
supplying,  transporting,  and  maintaining  systems.  The  reprogramming 
of  embedded  computer  software  has  placed  AFLC  in  an  engineering 
intensive,  mission-oriented  position.  This  role  change  is  symptomatic 
of  technological  advances,  bringing  both  technical  and  management 
difficulties.  To  complement  the  significant  strides  made  by  AFLC  in 
preparing  for  the  impact  of  digital  technology,  this  study  was  com¬ 
missioned  to  examine  critically  the  AFLC  current  ECS  support  posture 
to  determine  if  the  support  posture  could  be  more  efficiently  aligned  to 
current  and  future  support  requirements.  The  following  are  the  most 
important  management  issues  as  determined  by  this  study. 

•  ECS  readiness  support  concept 

•  Personnel  and  training 

•  Microprocessors  and  firmware 

•  AFR-800  versus  AFR-300  acquisition  and  support 

•  ConfiguraHon  management 

•  Facility  planning,  funding,  and  maintenance 

•  Funding 

•  Product  and  data  quality  at  transition 

•  Management  structure 
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Table  2-1.  Major  Study  Topics  and  Supporting 
Data  References 


^  Requirements  Baselines  (Section  2.  2) 


2.1.1  ECS  Readiness  Support  Concept^ 

Many  electronic  warfare  and  weapon  systems  currently,  or  in  the 
near  future,  under  the  support  responsibility  of  AFLC  are  impacted  by 
changes  in  adversary  threats.  As  the  threats  change,  the  capabilities 
of  friendly  systems  need  to  be  updated  accordingly.  The  frequency  and 
significance  of  threat  changes  are  such  that  rapid  reaction  to  the  threats 
is  tantamount  to  the  success  of  friendly  systems.  An  adequate  support 
posture  does  not  exist  to  meet  the  responsiveness  and  engineering 
sophistication  required.  Specifically,  deficiencies  fall  into  the  categories 
of  (1)  the  lack  of  sufficient  intelligence  support  to  the  ALC  organization 
responsible  for  software  engineering  to  determine  specific  threats,  and 
(2)  the  lack  of  a  concept  of  operations  and  designated  resources  (for 
other  than  EW  systems)  to  make  software  changes  in  response  to 
adversary  actions  and  capabilities.  Today's  AFLC  ECS  manager  must 
have  access  to  intelligence  data  that  reflects  adversary  intentions  and 
hard  technical  data  on  the  threat  e:i-  i/onment.  These  data  are  required  to 
provide  timely  engineering  support  in  fire  control  radars,  communications 
systems,  EW  systems,  etc.  In  addition,  resources  (equipment,  facilities, 
and  personnel)  must  be  available  to  provide  software  changes  to  counter 
observed  threats  in  either  a  pre-emptive  or  quick  reaction  capability  (QRC) 
mode. 

RECOMMENDATIONS 

t  Initiate  actions  that  will  provide  a  stimulus  and 

effectiveness  monitoring  capability  for  key  avionics 
systems.*  These  actions  should  include: 

•  Investigation  of  incorporating  basic  stimulus  and 

monitoring  equipment  as  an  integral  part  of  each  AISF. 


*  Detailed  discussion  in  Section  2,  Volume  n. 

Key  systems  should  include,  but  not  be  limited  to,  terrain  avoidance/ 
terrain  following  radars,  fire  control/nav  aid  radars,  IFF  and  selected 
communications  system.  Particular  emphasis  should  be  given  to  the 
F-15,  F-16,  E-3A,  F-lll,  and  JTLDS  systems. 
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•  Should  this  approach  be  taken,  then  an  overall  AFLC 
management  oversight  program  should  be  implemented 
to  ensure  that  the  stimulus  and  the  monitoring /data 
reduction  within  each  AISF  is  standardized,  that  the 
results  are  transferable,  and  that  the  intelligence 
data /stimulus  waveforms  are  "valid"  and  universally 
used  throughout  the  ALC's. 

•  Investigation  of  the  feasibility  of  using  an  Electronic 
Warfare  Open  Loop  Simulation  (EWOLS)  similar  to 
that  being  developed  at  WR-ALC/MMR.  Using  this 
approach,  the  current  EWOLS  concept  would  be 
expanded  to  include  the  capability  to  generate  various 
jamming  waveforms. 

^  At  the  same  time,  emphasis  should  be  placed  on  docu¬ 
menting  and  developing,  as  an  integral  part  of  the 
stimulus /monitoring  equipment,  a  pre-emptive  engineering 
and  QRC  support  capability.  Under  this  concept,  the 
stimulus /monitoring  equipment  not  only  serves  to  stimulate 
and  evaluate  the  baseline  data/avionics  system,  but  also 
allows  the  evaluation  of  changes  to  both  the  stimulus  and 
the  avionics  system  in  a  pre-emptive  engineering  and  QRC 
development  and  test  role. 

t  Rank  fire  control  radars  and  associated  "core  of  trained 
personnel"  as  first  priority  among  avionics  systems. 

The  following  ranking  rationale  applies. 

e  These  systems  are  currently  deployed  in  the  field  and 
with  the  development  of  the  "beyond  visual  range"  air- 
to-air  missiles,  it  is  essential  that  these  systems  be 
capable  of  undegraded  performance  in  an  ECM 
environment. 

•  The  numerical  superiority  of  the  Soviets  in  a 
Central  European  environment  requires  the  F-15/ 

F-16  systems  be  able  to  engage  effectively  with 
extended  "beyond  visual  range  missiles"  and  to  do 
so  with  a  high  confidence  kill  probability  on  a  single 
shot  basis. 

•  Soviet  REC  is  targeted  against  U.S.  fire  control  radars. 
One  of  the  specific  objectives  of  this  targeting  approach 
is  to  deny  U.S.  aircraft  the  advantage  of  long-range 
directed  air-to-air  missile  engagements. 


$  Train  and  maintain  within  each  support  facility  a 
core  of  expertise. 

t  Conduct  an  extensive  review  of  the  current  and  future 
ALC's  mission  and  document  requirements  for  use 
and  storage  of  classified  data  including  both  "Friendly/ 

-Blue"  and  Foreign  Intelligence  Data. 

The  following  should  be  included  in  this  review. 

•  Identification  of  the  type  and  classification  of  the 
various  ALC  ECS  support  facilities  as  a  function  of 
both  the  classified  intelligence  material  handling/ 
storage  and  the  classified  nature  of  the  "Friendly/ 

Blue"  systems.  This  effort  should  include  not  only 
a  review  of  the  overall  facility  classification,  but 
also  identification  of  required  work  areas  and  con¬ 
ference  facilities. 

•  Analysis  and  identification  of  the  type,  number,  and 
level  of  classification  of  the  personnel  required  to 
support  each  ALC. 

•  Documentation  and  implementation  of  appropriate 
HQ  AFLC  direction  in  the  area  of  specific  responsi¬ 
bilities  for  obtaining  and  providing  the  required 
intelligence  support  at  the  various  ALC's.  Specific 
consideration  should  be  given  to  publication  of  an 
AFLC  implementation  regulation  for  AFR  200-1. 

•  Based  upon  the  above  work,  development  of  a  command¬ 
wide,  long-range  plan  for  obtaining,  storing,  and  work¬ 
ing  with  foreign  intelligence  data. 

t  In  coordination  with  operational  commands  and  the  intelligence 
community,  develop  a  concept  of  operations  for  reprogram¬ 
ming  critical  mission  embedded  computer  systems.  The 
EWIR  concept  used  for  EW  reprogramming  may  be  used 
as  a  guide. 

2.1,2  Personnel  and  Training^ 

With  USAF  tactical  and  strategic  effectiveness  weighing  more  and 
more  heavily  upon  the  ability,  to  provide  highly  interactive,  rapidly 
responding,  economical  embedded  computer  system  support,  the 


t 


Detailed  discussion  in  Section  3,  Volume  II. 
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dependence  upon  AFLC  human  resources  with  engineering  and  computer 
science  skills  will  heighten  markedly  in  the  1980's.  Approximately 
3,500  organic  personnel  (collectively  costing  on  the  order  of  $100  million 
per  annum)  are  projected  for  the  five  Air  Logistic  Centers  in  FY  86. 

This  projection  is  twice  today's  authorized  manning  level.  Acquiring, 
training,  and  retaining  such  an  organic  work  force,  particularly  with 
the  skill  mix  required,  presents  a  mammoth  challenge.  Many  of  the 
undesirable  characteristics  inherent  in  the  current  personnel  and  train¬ 
ing  area  deepen  this  challenge.  Among  the  chief  issues  are:  (1)  inade¬ 
quacies  in  the  manpower  requirements,  definition  and  planning  process, 
and  in  the  manpower  justification  and  authorization  process  as  well  as 
in  the  recruiting  activities;  (2)  short-comings  in  personnel  training, 
source  selection,  training  plans,  funds,  and  scheduling;  and  (3)  problems 
related  to  promotional  policies,  responsibility  and  authority  balance, 
professionalism,  and  technical  challenges. 

RECOMMENDATIONS 

t  Develop,  within  guidance  provided  by  Headquarters  AFLC 

(e.g.,  via  AFLCR  800-21,  AFLCR  400-XX) 

•  Detailing  of  the  various  support  concepts  and  alter¬ 
natives  (and  accompanying  decision  rationale)  requisite 
in  arriving  at  an  optimum  approach  (i.  e.  ,  a  more 
detailed  version  of  the  logic  paths  sketched  for  the 
AFLC  Generic  Logistic  Decision  Tree  in  AFLCR 
400-XX).  A  definative  breakout  of  governmental 

and  readiness  functions  should  be  included. 

Organic  staffing  logic  based  upon  an  average 
employee  tenure  of  4  to  7  years,  rather  than  the 
usual  15  to  20  years,  is  recommended. 

•  Specific  guidance  and  policy  regarding  the  con¬ 
solidation  of  resources  (including  cross-training) 
across  ALC's  and  ECS's. 

•  A  generic  breakout  of  functions  and  activities 
required  in  the  software  operations  and  support 
job  for  a  given  ECS  as  well  as  for  a  multi-ECS 
environment. 

•  A  skill  level  index  with  associated  position  des¬ 
criptions  and  manpower  quantity  algorithms. 
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•  A  step-by-step,  time-phased  trace  depicting  the 
manpower  acquisition  (authorization)  process, 
including  new  starts  and  other  additive  elements, 
as  well  as  a  responsibility  breakdown  between 
Headquarters  AFLC  offices,  ALC  offices,  and 
Manpower  Evaluation  Teams. 

•  An  expansion  of  the  CRISP  content  to  include 
contingency  planning  for  embedded  computer 
resources  in  the  event  manpower,  funding, 
and  Military  Construction  Programs  inherent 

in  the  primary  support  role  are  delayed  or  denied. 

P  Take  steps  to  have  software  manpower  removed  from  the 
"additive"  category  and  placed  in  the  manpower  baseline 
with  other  operations  and  maintenance  functions. 

P  Continue  attempts  to  establish  special  categories  and 
high  grade  authorizations  for  ECS  engineers. 

^  Develop  a  top  level  training  plan,  in  coordination  with  ATC 
and  AFIT  for  ECS  operations  and  support  engineers  and 
managers.  The  development  of  a  formal  training  pro¬ 
gram  (such  as  is  currently  conducted  for  flight  training, 
maintenance  officer's  school  and  logistics  management 
school)  for  software  engineers  and  for  software 
managers  is  strongly  urged. 

t  Establish  in  Headquarters  AFLC  a  senior  position  for  an 
expert  in  ECS  operations  and  support  who  has  first-hand 
experience  in  the  problems  encountered  by  the  ALC's. 

This  position,  which  might  be  rotational  in  nature, 
should  be  filled  from  the  ALC's.  The  chief  role  of  this 
position  would  be  to  interact  with  the  ALC's  and  to 
provide  inputs  to  and  participate  in  the  command-wide 
ECS  support  planning  and  decision  process. 

2.1.3  Microprocessors  and  Firmware^ 

The  unique  problems  brought  about  by  the  massive  influx  of  micro¬ 
processors  and  firmware  into  current  avionics  systems  impact  both 
technical  and  management  considerations.  From  an  AFLC  standpoint, 
establishing  a  comprehensive  support  posture  requires  an  understanding 


t 


Detailed  discussion  in  Section 


4, 


Volume  II. 
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and  resolution  of  these  unique  aspects-  Major  problems  impacting 
support  of  microprocessors  and  firmware  are:  (1)  lack  of  common 
definitions,  procedures,  configuration  management  practices,  and 
policies  for  use  within  AFLC  and  AFSC;  (2)  lack  of  standard,  well- 
equipped  microprocessor  support  facilities;  (3)  additional  requirements 
placed  on  logistic  planning;  and  (4)  lack  of  common  agreement  with 
AFSC  concerning  data  requirements. 

RECOMMENDATIONS 

♦  Formulate  a  joint  AFSC /AFLC  regulation  concerning  micro¬ 
processor  and  firmware  definitions,  concept  of  operations, 
configuration  management  practices ,  policies,  and  pro¬ 
cedures.  This  effort  should  include  policies  on  HOL's  and 
data  requirements  and  the  need  for  firmware  DID's. 

t  Develop  and  install  a  standard,  well -equipped,  growth- 
oriented  microprocessor  laboratory  at  AGMC  and  each 
of  the  five  ALC's. 

2.1.4  AFR-800  versus  AFR-300  Acquisition  and  Support^ 

Currently,  ECS  support  organizations  are  unsure  about  the  inter¬ 
pretation  of  existing  directives  pertaining  to  the  procurement  of  com¬ 
puters  used  in  the  support  of  avionics  systems.  This  uncertainty  stems 
from  implementing  regulations  describing  two  approval  processes  to 
satisfy  the  intent  of  Public  Law  89-306  (Brooks  Bill).  AFR-800  and 
AFR-300  series  regulations  define  different  approval  and  procurement 
paths  for  weapon  system  and/or  support  system  computers  and  other 
system  components.  Most  ECS  support  managers  agree  that  embedded 
computer  resources,  including  ECS  support  facility  computers,  should 
be  exempt  from  the  AFR-300  series  acquisition  policy  but  they  concede 
that  DOD  guidance  is  not  sufficiently  clear.  The  Joint  Logistics 
Commanders  have  prepared  and  submitted  candidate  changes  to  improve 
the  clarity  of  DODD  5000.29  in  order  to  define  clearly  embedded  com¬ 
puter  resources  and  include  commercial  computers  if  they  are  integral 
to  an  operational  or  supporting  system.  These  changes  should  be  adopted. 


Detailed  discussion  in  Section  5,  Volume  II. 
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2.1.5  Configuration  Management^ 

To  fully  capitalize  upon  the  weapon  system  flexibility  facilitated 
through  embedded  computer  system  software,  an  effective,  efficient 
configuration  identification,  control,  and  status  accounting  system  is 
mandatory.  Although  configuration  management  for  hardware  has  been 
implemented  quite  successfully,  software  (less  visible,  more  pervasive) 
has  not  been  as  manageable.  The  chief  difficulities  in  ECS  software 
configuration  management  are:  poorly  established  configuration  item 
baselines,  less  than  adequately  defined  change  control  methods,  and 
inadequate  motivation  and  resources  to  implement  effective  procedures. 
Establishing  more  detailed  procedures  and  tools  which  are  standard 
across  ECS's,  placing  emphasis  on  pre-deployment  IV&V,  and  invoking 
more  crisply  defined  roles  and  missions  in  C-E  and  ATD  will  lead  to 
more  effective  ECS  software  CM  in  the  1980's. 

RECOMMENDATIONS 

t  Detail  the  configuration  management  guidance  provided 
in  AFR  800-14  andAFLCR  800-21  into  ALC  division  and 
branch  level  procedures,  advisedly  in  the  form  of  operating 
instructions  (OI's).  Action  should  be  taken  by  Headquarters 
AFLC  to  ensure  that  such  procedures  are  consistent  across 
all  ECS' s  (i.  e. ,  OFP,  EW,  ATD,  C-E).  These  OI' s  should 
be  employed  as  items  for  AFLC  functional  inspections. 

t  To  enhance  accuracy,  speed,  and  cost  effectiveness, 

develop  a  common  set  of  CM  tools  (e.g.,  data  management 
systems,  requirements  tracing  tools,  library  systems) 
across  ALC's  and,  where  applicable,  across  ECS  types. 

t  Conduct  a  tradeoff  analysis  to  evaluate  centralized  change 
management  as  opposed  to  a  decentralized  process  (for 
C-E  and  ATD).  Roles  and  missions  of  involved  agencies 
should  be  carefully  considered.  If  split  software  support 
is  determined  necessary  for  a  special  situation,  then 
support  should  be  aggregated  at  one  location  with  CM  per¬ 
formed  as  a  consolidated  and  coordinated  effort. 


t 


Detailed  discussion  in  Section  6,  Volume  II. 


2-9 


+ 

2.1.6-  Facility  Planning.  Funding,  and  Maintenance 

The  timely  establishment  of  ECS  software  support  facilities  is 
integral  to  a  post -deployment  software  operations  and  support  capability. 
The  maintenance  of  such  facilities  over  the  life  cycle  of  the  system  is  of 
equal  importance.  The  planning  process  for  the  ECS  support  facility 
involves  explicitly  defining  all  requirements,  defining  a  support  concept, 
estimating  the  cost  of  items  to  be  acquired  and/or  developed,  and 
obtaining  the  necessary  approvals  for  the  funding.  This  process  is 
entwined  in  the  federal  budget  and  the  Military  Construction  Program 
cycle  and  can  span  years.  Changing  personnel,  poorly  defined  system 
and  support  requirements,  cost  changes,  maintenance  concepts,  etc. 
that  accompany  this  drawnout  process  only  compound  the  delays.  In 
addition,  there  are  concerns  that  AFSC  does  not  always  provide  adequate 
attention  to  life  cycle  support  and  that  software  development  facilities  may 
be  unavailable  or  inappropriate  for  post -deployment  use.  Action  at  all 
levels  of  USAF  management  will  be  necessary  to  ensure  an  effective, 
efficient  software  operations  and  support  posture  in  the  1980' s. 

RECOMMENDATIONS 

^  Develop  a  coordinated  set  of  AFLC/AFSC  guidelines  for 
establishing  and  maintaining  post -deployment  software 
support  facilities.  These  guidelines  should  address  the 
gamut  of  planning,  development,  integration,  demonstra¬ 
tion,  and  maintenance  activities  as  well  as  documentation 
requirements  necessary  to  ensure  ta  t  a  timely,  effective 
and  efficient  operations  and  support  capability  results. 

The  Software  Acquisition  Engineering  Guidebook  for 
Software  Development  and  Support  Facilities  recently 
developed  by  TRW  under  contract  to  AFSC,  for  Aero¬ 
nautical  System  Division  and  Space  Division,  provides 
a  solid  basis  for  such  guidelines. 

^  Develop  checklists  related  to  the  Program  Management 
Directive,  Program  Management  Plan  and  the  Integrated 
Logistics  Support  Plan  which  can  be  used  by  Headquarters 
USAF,  AFLC,  AFALD  and  field  agencies  participating  in 
ECS  acquisition  to  ensure  that  these  documents  properly 
address  support  facilities,  USAF/LE  should  be  encouraged 
to  non-concur  on  all  PMD's  which  do  not  adequately  address 
post-PMRT  support  facilities. 


t 
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^  Incorporate  facility  planning  and  funding  as  part  of  the 

DSARC/AFSARC  process,  including  these  as  specific  items 
in  the  DOD  Embedded  Computer  Resources  and  DSARC 
Process  Guidebook. 

^  Establish  software  support  facilities  as  early  as  possible 
in  the  acquisition  cycle  to  maximize  the  benefits  of  the 
total  spectrum  of  AFLC  pre-deployment  activities. 

2.1.7  Funding  * 

The  change  from  traditional  AFLC  activities  to  a  more  engineering 
intensive,  mission-oriented  role  has  been  accompanied  by  a  lack  of 
appropriate  funding  initiative.  A  most  notable  example  is  the  need  for 
sophisticated  support  systems  that  require  long  lead  times,  are  costly, 
and  for  which  the  need  is  not  always  understood.  Management  consider¬ 
ations  can  lead  to  budgeting  and  approving  funds  which  are  consistently 
short  of  real  costs.  As  a  result,  these  budgeting  deficits  are  countered 
with  sacrificed  product  quality,  documentation  waivers,  austere  training, 
and  limited  travel.  The  overall  effect  of  shortfalls  in  funding  is  a  net 
increase  in  the  resources  required  to  provide  ECS  support  from  a  life- 
cycle  perspective. 

RECOMMENDATIONS 

t  Establish  definitive  funding  lines  within  AFR  800-14  and 
the  PMD's  to  route  pre-PMRT  funds  to  AFLC  agencies 
to  enable  adequate  participation  in  the  acquisition  process, 
acquire  appropriate  operations  and  support  software 
support  facilities,  perform  and  participate  in  IV&V 
activities,  and,  in  summary,  establish  support  capabilities. 

2.1.8  Product  and  Data  Quality  at  Transition* 

Despite  affirmative  steps  taken  to  improve  product  quality  at  PMRT, 
inadequately  tested  software,  accompanied  by  insufficient  data  and  support 
tools,  continue  to  be  transitioned  to  AFLC.  Particular  difficulties  in  this 


Detailed  discussion  in  Section  8,  Volume  II. 
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regard  have  been:  (-1)  non-standard  and  unsupportable  languages; 

(2)  inadequate  data  provided  on  the  software  and  the  system;  (3)  unavail¬ 
ability  and  inadequacy  of  support  tools;  (4)  lack  of  standardization  and 
commonality  considerations;  (5)  limited  growth  potential  in  the  target 
computers;  (6)  incompleteness  of  development,  i.  e.  ,  baseline;  and 
(7)  absence  of  a  demonstration  of  supportability.  Additional  AFLC/ 

AFSC  guidance,  more  direct  involvement  of  AFLC  in  Full  Scale 
Engineering  Development,  the  adoption  of  more  definitive  ECS  Docu¬ 
mentation  requirements,  and  the  development  of  a  guidebook  for  ECS 
source  selection  are  avenues  to  the  alleviation  of  these  problems  for 
ECS's  transitioning  in  the  1980's. 

RECOMMENDATIONS 

^  Develop  an  embedded  computer  resources  guidebook 
for  use  by  AFLC  personnel  participating  in  source 
selection  activities.  This  guidebook  should  delineate 
ECS  life-cycle  support  considerations  and  documenta¬ 
tion  and  data  issues  as  well  as  the  ECS  development 
methodology  issues. 

^  Adopt  a  formal  means  of  directly  and  actively  involving 
the  designated  supporting  ALC  in  the  ECS  acquisition 
cycle  sufficiently  in  advance  of  PMRT  to  ensure  that 
a  high  quality  of  well-baselined  software  and  related 
documentation  exists  at  transfer  and  that  sufficient 
resources  (personnel,  training,  equipment,  facilities, 
support  software,  etc.  )  are  available  to  AFLC  to 
carry  out  timely  life -cycle  operations  and  software 
support.  It  is  urged  that,  as  part  of  this  approach, 
the  designated  supporting  ALC  perform  predeploy¬ 
ment  IV&V  on  development  software  and  demonstrate 
a  software  support  capability  as  a  pre-requisite  for 
transfer.  These  provisions  should  be  made  part  of 
the  AFR  800-4  PMRT  plan. 

^  Establish  joint  AFSC /AFLC  regulatory  guidance  that 
requires  AFLC  approval  prior  to  any  reprogramming 
of  funds  allocated  for  AFLC  requirements  to  other 
acquisition  areas. 
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2.1.9  Management  Structure^ 

The  management  structure  of  AFLC  is  the  result  of  an  evolution 
spanning  several  years.  With  few  minor  exceptions,  the  structure  has  not 
been  significantly  altered  to  meet  requirements  for  the  support  of  ECS 
software.  The  structure  was  primarily  developed  to  provide  support  to 
systems  and  items  with  primary  emphasis  on  the  hardware  involved.  The 
structure  was  further  designed  to  achieve  optimum  spare  and  repair 
support  without  specific  regard  to  engineering  development.  As  the  AFLC 
role  has  changed  in  recent  years,  particularly  in  regard  to  ECS  software 
support,  organizational  adjustments  may  be  warranted. 

Recommendations  for  specific  changes  in  ALC  organization  structure 
are  not  within  the  scope  of  this  study,  the  advantages  and  disadvantages  of 
several  alternatives  are  discussed  in  Volume  II.  Further  analysis  of 
these,  or  other,  organizational  concepts  would  best  be  performed  as 
an  organic  USAF  effort. 
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Detailed  discussion  in  Section  10,  Volume  II. 
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2.2  REQUIREMENTS  BASELINES 


The  requirements  baseline  discussions  and  recommendations 
relating  to  ECS  software  and  associated  documentation,  support  tools, 
and  support  policy  and  guidance  resulted  from  investigation  and  analysis 
of  the  current  AFLC  ECS  support  baselines.  Other  ECS  problem  areas 
associated  with  each  ECS  category  are  discussed  in  Volumes  III  through 
VII.  In  this  overview,  a  specific  problem  area  is  briefly  outlined  and  its 
general  affiliation  with  the  ECS  categories  is  described.  Recommendations 
are  provided  for  each  problem  addressed. 

2.2.1  ECS  Software  and  Associated  Documentation 

The  documentation  describing  weapon  system  and  ECS  baselines 
is  not  adequate  to  facilitate  efficient  post-PMRT  software  development 
and  support.  Most  documentation  development  has  been  an  AFSC 
responsibility;  however,  in  certain  EW  systems,  the  responsibility  has 
rested  with  AFLC.  Inadequate  documentation  ( e. g. ,  no  source  listing, 
no  algorithm  descriptions,  mismatches  between  the  software  and  its 
description,  etc.)  are  common-place  in  all  five  ECS  categories.  This 
deficiency  directly  impacts  ECS  support  and  configuration  control 
because  the  initial  product  baseline  is  not  adequately  defined. 

Documentation  format  and  the  limits  of  coverage  are  inconsistent 
from  system  to  system.  Engineering  data  usually  is  the  basis  upon  which 
technical  order  data,  users  and  operators  manuals,  etc.  are  centered. 
Subsequent  changes  to  the  multiplicity  of  documents  are  processed  very 
slowly  and,  in  some  ATD  examples,  the  process  takes  2  years  or  more. 
Change  responsiveness  is  slow  in  all  of  the  ECS  categories  to  the  extent 
that  significant  improvement  is  necessary. 

Delivered  software  products  have  not  generally  been  of  sufficient 
quality  to  facilitate  efficient  software  support  within  AFLC.  This  limita¬ 
tion  has  sometimes  necessitated  continued  development  of  both  the  opera¬ 
tional  and  support  software.  All  ECS  categories  experience  this  effect 
to  some  extent  with  ATE  and  EW  the  most  pronounced  categories.  Inade¬ 
quate  quality  of  software  product  baselines  directly  impacts  AFLC's 
subsequent  software  development  and  support  efforts. 
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Air  Force  regulations  as  well  as  good  engineering  practices 
dictate  that  an  alternative  geographical  location  be  provided  for  copies 
of  software  masters.  That  is,  a  copy  is  preserved  at  a  site  other  than 
the  main  control  site  so  that  inadvertent  or  intentional  destruction  of  a 
master  is  not  catastrophic  to  the  software  support  capability.  All  ECS 
categories  have  a  need  for  a  software  repository  to  preserve  copies  of 
software  masters. 

RECOMMENDATIONS 

^  Emphasize  delivery  of  quality  documentation  and  auditing 
documentation  for  adequacy  and  overall  quality  during 
acceptance  testing  prior  to  PMRT. 

^  Initiate  action  to  design,  develop,  and  acquire  an  auto¬ 
mated  documentation  system  which  could  be  used  for 
maintaining  and  updating  engineering  and  technical 
order  data. 


^  Intensify  efforts  with  AFSC  to  stress  quality  of  software 
in  weapon  and  support  systems.  A  more  active  and 
aggressive  role  in  design  reviews,  contractor  develop¬ 
ment  progress  monitoring,  and  testing  is  required. 

In  addition,  AFLC  should  specify  acceptance  test 
criteria  prior  to  accepting  PMRT. 

^  Initiate  action  to  design,  develop,  and  acquire  a  software 
repository  for  storing  copies  of  all  ECS  software  masters. 


2.2.2  ECS  Support  Tools 


In  many  cases,  continued  development  of  software  is  required 
after  PMRT  and  the  software  tools  originally  used  to  develop  weapon 
system  and  support  system  software  are  not  delivered  to  AFLC.  These 
tools  are  necessary  and  thus  must  be  procured  or  developed  by  AFLC 
personnel.  A  large  number  of  these  tools  are  required,  particularly 
in  the  EW  and  OFP  categories.  Currently,  insufficient  attention  is 
being  given  to  developing  universal  software  tools  which  could  aid  in 
software  support  of  any  or  all  ECS  categories;  instead,  tools  are  being 
developed  for  "near  unique"  applications. 
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All  ALC's  have  configuration  management  problems  to  some  degree. 
The  problems  span  all  ECS  categories  and  generally  are  the  result  of 
lack  of  implementation  rather  than  lack  of  procedural  and  regulatory 
guidance.  Although  lack  of  documentation  intensifies  the  configuration 
management  problems,  configuration  management  problems  exist  even 
where  baselines  are  adequately  described.  Several  configuration  manage¬ 
ment  activities  are  underway  at  the  ALC's,  but  none  have  been  adopted 
as  a  standard  for  operation  of  all  AFLC  agencies. 

Support  systems  have  grown  in  complexity  to  the  extent  that 
operational  verification  can  be  a  significant  proceeding.  Such  capabilities 
as  exercise  scenarios,  simulations,  and  emulations  are  required  to  both 
verify  and  to  exercise  support  stations.  These  tools  are  particularly 
applicable  to  the  EW  and  OFP  categories  and  to  a  lesser  degree,  to  the 
other  categories. 

RECOMMENDATIONS 

^  Adopt  a  command-wide  configuration  management  system 
for  use  by  the  ALC's.  The  configuration  management 
should  encompass  automatic  features  that  enhance 
system  operating  ease  and  utility  and  that  adequately 
control  all  necessary  ECS  data. 

^  Identify  software  development  tools  envisioned  as  being 
needed  within  the  next  5  years  and  then  structure  an 
approach  to  acquiring  the  tools  through  off-the-shelf 
procurement,  in-house  development,  or  contractor 
development. 

^  When  possible  AFLC  should  design  and  develop  or 

acquire  standard  scenario  and  simulator  inputs  to  verify 
support  systems.  This  approach  should  be  extended 
to  an  entire  set  of  IV&V  capabilities. 

2.2,3  ECS  Support  Policy  and  Guidance 


Aircrew  training  devices  and  simulators  are  often  developed  with 
substantial  architectual  differences  from  their  representative  weapon 
systems  and  avionics.  Consequently,  a  change  to  the  weapon  system 
does  not  necessarily  correlate  to  a  similar  change  in  the  ATD.  In  fact. 


these  changes  are  often  independent  to  the  extent  that  redesign  of  the  ATD 
or  simulator  is  necessary.  This  problem  could  be  reduced  by  ensuring 
more  commonality  of  equipment  components  and  software  between  the 
weapon  system  and  its  trainer  or  simulator. 

Support  of  ECS  software  is  an  engineering  intensive  activity. 

Current  logistics  procedures  and  regulations  need  to  be  reassessed 
in  the  context  of  efficient  application  to  this  rapidly  increasing  engi¬ 
neering  role.  Also,  recent  acquisition  emphases  on  such  areas  as 
interoperability,  standardization,  and  design  for  testability  need  to  be 
solidified  into  guidelines  for  both  AFSC  and  AFLC.  The  result  of  applying 
these  emphases  should  lessen  the  overall  support  demands  upon  AFLC 
in  future  years. 

As  operational  capabilities  of  weapon  systems  have  become  more 
integral  with  ECS  software  so  has  intelligence  data  become  more  integral. 
Software  changes  for  EW  and'OFP  systems  are  very  dependent  upon 
real-time  intelligence  data  inputs.  The  potential  for  C-E  and  ATD  use 
of  real-time  intelligence  data  is  high.  Reliance  upon  intelligence  data 
indicates  a  more  intimate  interface  with  intelligence  agencies  is 
necessary  if  ECS  support  is  to  be  provided. 

RECOMMENDATIONS 

t  Coordinate  with  AFSC  and  adopt  a  policy  which  maximizes 
consistency  between  weapon  system  and  ATD's  and 
avionics  and  simulators. 

t  Establish  a  group  to  assess  the  applicability  of  existent 
regulations,  procedures,  and  organization  to  the  esca¬ 
lating  engineering  role  in  AFLC. 

t  Establish  an  AFLC  group  to  determine  the  extent  of 
interoperability,  standardization,  design  for  testing, 
etc.,  that  is  practical  for  AFSC/AFLC  implementation. 

t  Begin  budget  and  implementation  planning  to  conceptu¬ 
alize  the  AFLC  /Intelligence  interface  and  an  approach 
to  acquisition  of  necessary  AFLC  capabilities. 
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2.3  ECS  TECHNOLOGY  FORECAST 


TRW  technologists  forecast  the  effect  of  technological  advances 
that  will  occur  during  the  next  ten  years  on  AFLC's  support  of  embedded 
computer  systems.  The  ECS  technology  forecast,  described  in  Volume 
VIII,  is  driven  by  two  key  trends. 

1.  Accelerated  proliferation  of  microprocessors,  avionics 
computers,  and  special-purpose  processors  within  Air 
Force  weapon  systems  and  test  equipment  is  envisioned 
during  the  next  ten  years.  More  subsystems  will  be 
equipped  with  internal  circuit-board  computers,  thus 
displacing  many  stand  alone  embedded  computer  systems. 

2.  Demographers  expect  the  college-age  population  to  be 
2.  5  million  students  less  in  1990  than  during  the  1970's 
peak.  AFLC  will  need  to  train  thousands  of  new  pro¬ 
grammers  and  computer  technicians  during  the  next 
ten  years.  An  increase  in  productivity  will  become 
essential  if  AFLC  is  to  maintain  the  readiness  of  Air 
Force  equipment. 

Nine  technology  advances  have  been  identified  that  will  strongly 
affect  AFLC's  support  of  ECS  during  the  next  ten  years.  In  connection 
with  each  technology,  specific  actions  are  recommended.  Also 
recommended  are  four  management-oriented  initiatives  that  will  assist 
AFLC's  economic  adaptation  to  the  technological  advances. 

2.3.1  Intercenter  Networks^ 


It  is  feasible  to  interconnect  all  ALC's  and  Headquarter  AFLC  with 
a  communication  net,  whose  bandwidth  could  be  4  KHz  (telephone  lines) 
to  6  MHz  (satellite  lines).  The  network  could  be  used  for 

•  Closed  Circuit  Television  (CCTV),  as  a  training  and 
conferencing  aid; 

•  Distributed  Integration  Support  Facility  (ISF) 
simulations;  and 

•  Operator-interactive  data  exchange  (management 
information,  software,  inventory,  and  scientific  computing). 
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Detailed  discussion  in  Section  2,  Volume  VIII. 
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This  intercenter  net  would  increase  productivity  of  the  technical  staff, 
avoid  duplicate  development,  and  reduce  training  costs. 

RECOMMENDATIONS 

^  Analyze  intercenter  needs  (number  of  users,  data 

rates,  time  delays,  encryption,  etc.)  and  costs  associate 
with  alternative  implementations  on  a  priority  bases. 

An  AFLC  skill  center  should  be  charged  with  the 
analysis  and  subsequent  implementation. 

2.3.2  Distributed  Integration  Support  Facilities^ 

Distributed -ECS  avionics  are  being  used  in  many  new  weapon 
systems.  The  embedded  distributed  computers  serve  such  things  as  the 
radars,  weapon  delivery,  engine  control,  air  data,  flight  control,  IFF- 
fusion,  navigation,  air  data,  digital  radio,  cockpit  displays,  electronic- 
warfare  pods,  and  optic  pods.  Integration  Support  Facilities  (ISF)  use 
simulations  of  those  subsystems  and  their  environment  for  the  following 
purposes: 

•  software  maintenance, 

•  hardware  integration,  and 

•  hardware  maintenance  (for  "check-out-ok"  LRU's). 

Distributed  Integration  Support  Facilities  (ISF's)  are  those  in 
which  subsystem  simulations  are  located  at  several  different  ALC's. 
Distributed  ISF's  should  share  expensive  host  computers,  peripherals, 
sensor  stimulus  generators,  etc.  among  several  weapon  systems  and 
should  concentrate  scarce  specialists  into  skill  centers.  The  network 
cost  may  offset  the  saving  in  duplicate  facilities  but  scheduling  may 
present  management  problems.  A  preliminary  analysis  by  TRW  suggests 
that  56  kbps  one-way  data  rates  and  iO  msec  intercenter  time  delays 
are  required. 
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Detailed  discussion  in  Section 


3, 


Volume  VHI. 
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■  RECOMMENDATIONS 


t  A  distributed  ISF  should  be  simulated  by  AFLC  at  a 

collocated  ISF,  such  as  Sacramento,  to  determine  the 
required  data  rates,  error  rates,  and  maximum  allow¬ 
able  time  delay.  A  distributed  ISF  should  be  compared 
to  a  collocated  ISF  using  those  data  rates  and  using 
estimates  of  usage  times  in  support  of  anticipated 
US AF  programs.  The  output  would  be  comparative 
cost  and  manpower  for  the  two  ISF  concepts.  AFLC 
should  delegate  the  analysis  to  one  of  its  skill  centers 
for  implementation  of  an  AFLC -wide  ISF  plan. 

2.3.3  Computer  Nets* 

A  computer  net  is  the  interconnected  group  of  embedded  computers 
that  comprise  a  distributed  avionics  system.  These  embedded  computers 
perform: 

•  software  maintenance, 

•  hardware  integration,  and 

•  hardware  maintenance  (for  "check-out-ok"  LRU's). 

Nets  designed  by  AFSC  permit  each  subsystem's  computer  program  to  be 
written  by  the  vendor's  technology  experts  and  permit  some  degree  of 
fault  tolerance.  Inter-computer  connections  almost  universally  use  the 
MIL-STD  1553B  data  bus;  computers  will  soon  use  the  MIL-STD  1750A 
instruction  set  or  chips  that  execute  that  instruction  set. 

RECOMMENDATIONS 

^  Plan  for  ISF's  in  support  of  distributed  avionics. 

Distributed  ISF's  may  be  the  most  economic  solution 
to  software  support  and  hardware  integration  for 
distributed  avionics. 

^  Coordinate  with  AFSC 

•  To  include  extensive  built-in  test  (BIT)  in  avionics 
that  can  induce  and  verify  faults  in  fault-tolerance 
ECS  nets; 

•  To  provide  for  disabling  any  computer  in  the  net  to 
permit  testing  and  even  dispatch  with  a  failed  ECS; 
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Detailed  discussion  in  Section  4,  Volume  VIII. 
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•  To  avoid  general  multi-tasking  nets  although 
fallback-tasking  (in  which  each  computer  executes 
a  fixed  set  of  tasks  after  failures  in  the  net)  is 
acceptable  within  AFLC's  logistic  system  until  1990; 

•  To  confine  mission-related  software  changes  to 
one  computer  in  the  net;  and 

•  To  put  miss  ion -independent  changes  in  ROM  to 
eliminate  inadvertent  erasures. 

^  AFLC  should  analyze  automatic  test  equipment  versus 

BIT  requirements  and  make  appropriate  recommendations 
to  AFSC. 

^  Analyze  the  economics  of  using  MIL-STD  1750A  chips 
in  aircrew  trainers.  These  chips  offer  the  opportunity 
to  load  flight  computer  programs  directly  into  the  trainers 
with  few  changes,  instead  of  requiring  complete  re-coding 
as  at  present. 

2.3.4  LSI-VHSIC f 

Fast,  dense  LSI  chips  are  now  available  and  are  used  as  arithmetic/ 
logic  units,  clocks,  memory  elements,  and  input-output  devices  in  ECS. 
Special-purpose  processor  chips  are  being  incorporated  into  military 
computers  to  perform  correlations,  convolutions,  encryptions,  fast- 
fourier  transforms,  MIL-STD  1553B  bus  interfacing,  etc.  Chips  will 
shortly  be  available  that  execute  the  MIL-STD  1750A  instruction  set. 
Beginning  in  1984,  VHSIC  Phase  I  chips  will  be  commercially  available. 
These  chips  will  probably  have  densities  of  20,000  gates/chip  (as  opposed 
to  the  current  1000  gates/chip)  and  clock  speeds  of  25  MHz  (as  opposed 
to  the  current  6  MHz  clock  speeds).  These  chips  will  be  packaged  as 
are  today's  chips  and  will  be  mounted  on  circuit  boards. 

The  VHSIC  program  is  specifically  tailored  toward  military- 
unique  chips  that  are  not  produced  for  the  commercial  electronics  market. 
Thus,  AFLC  will  begin  to  find  them  embedded  in  every  variety  of 
electronics  equipment  and  in  replacement  devices.  Most  special-purpose 
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Detailed  discussion  in  Section  5,  Volume  VIII. 
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embedded  computers  will  be  incorporated  directly  into  the  devices  they 
support,  as  one  or  more  circuit  boards.  Standalone  computers  may 
bo  limited  to  central  general -pu  rpose  processors  in  communication 
station:'  or  Murvi-ill.im c  aircraft.  The  V1ISIC  program  will  develop 
radar -oriented  signal  processor  chips  that  will  replace  today's  pro¬ 
grammable  general-purpose  microcomputers.  LSI  and  VHSIC  micro¬ 
computers  will  also  be  used  in  optics  pods,  electronic-warfare  pods, 
and  communication  radios.  Special-purpose  navigation  communication 
chips  are  in  development  that  will  reduce  the  multiplicity  of  receivers 
and  transmitters  to  a  small  number  of  boxes  that  will  perform  the  same 
functions  with  higher  reliability.  Due  to  the  extensive  use  of  BIT  in 
chips  and  in  circuits,  flightline  ATE  may  nearly  disappear,  leaving 
an  array  of  computer-driven  special-test  equipment  in  maintenance  shops. 

The  adoption  of  a  standard  ECS  circuit  board  (either  an  input- 
output  standard  or  power,  environment,  and  size  standard)  by  AFSC 
would  greatly  simplify  logistics  and  repair. 

RECOMMENDATIONS 

^  Analyze  the  benefits,  if  any,  of  standardized 
internally  embedded  ECS  boards. 

t  Assist  in  the  development  of  microcomputer-based 
high  order  languages  and  compilers  for  the  ECS 
chips  to  be  found  in  retrofit  equipment.  Encourage 
AFSC  to  use  these  languages  in  new  equipment. 

The  languages  should  be  dialects  of  Ada  and  J73. 

f  Develop  software  tools  appropriate  to  each  micro¬ 
computer  or  encourage  AFSC  to  use  the  same  tools 
across  many  programs, 

^  Procure  special-purpose  hardware  to  support  LSI/ 

VHSIC,  such  as  logic  analyzers,  PROM  programmers, 

ROM  simulators,  and  hot  benches  for  testing  inter¬ 
faces  among  distributed  computers. 

^  Develop  ISF's  appropriate  to  each  distributed 
avionics  system. 
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2.3.5  High  Order  Languages* 

A  high  order  language  (HOL)  is  an  English-like  language,  with  a 
vocabulary  and  syntax,  whose  compiler  automatically  writes  machine 
instructions  for  a  computer.  DOD  had  150  languages  (not  all  HOL's) 
in  use  in  1978,  many  of  which  are  used  within  AFLC.  Various  DOD 
directives  of  the  late  1970's  require  that  future  software  be  written 
in  one  of  three  HOL's:  JOVIAL  J73,  Ada,  or  ATLAS. 

JOVIAL  J73:  The  J73  dialect  of  JOVIAL  is  the  language  in 
which  MX,  DAIS,  LANTIRN,  IUS,  and  other  software  are 
being  written.  J73  will  probably  be  used  in  the  upgrades 
of  KC-135,  F-lll,  E4,  and  the  Satellite  Control  Facility. 

Insofar  as  the  language  is  standardized  across  all  programs, 

AFLC  will  use  less  manpower  to  maintain  software  after 
PMRT.  AFLC  support  of  J73  will  begin  in  1983. 

Ada:  This  language  is  being  developed  by  DOD  and  is 
expected  to  become  standardized  in  the  NATO  countries 
in  1982.  Compilers  are  being  developed  but  no  program 
has  yet  adopted  it.  Ada  should  be  adapted  to  microcomputers 
and  might  also  be  used  for  distributed  multi-tasking  nets 
in  the  future.  AFLC  support  of  Ada  will  probably  begin 
in  1987. 

ATLAS:  This  language  is  a  well -developed  procedural 
language  that  produces  machine  code  from  English-language 
test  sequences  used  in  automatic  test  equipment.  It  is  easy 
to  read  and  use.  In  the  future,  ATLAS  statements  may  be 
translated  into  Ada  and  JOVIAL,  thus  unifying  all  of  AFLC's 
high  order  software.  An  interactive  version  of  ATLAS  may 
be  desirable  for  testing.  AFLC  will  support  ATLAS  through¬ 
out  the  1980  to  1990  period. 

The  amount  of  machine-language  and  assembly-language  pro¬ 
gramming  is  expected  to  decrease  as  HOL's  are  more  widely  used. 

When  used  at  all  in  AFLC,  low-level  languages  will  be  used  for  modifying 
operating  systems,  writing  input-output  programs,  and  sensor  interface 
routines. 
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RECOMMENDATIONS 

^  Consolidate  high  order  language  specialists  into 
a  central  skill  center  or  centers. 

^  Enforce  AFSC  usage  of  standard  Ada,  JOVIAL,  and 
ATLAS  on  all  new  programs  by  identifying  the  cost 
of  deviations  at  early  DSARC  reviews. 

^  Develop  or  encourage  AFSC  to  develop  problem- 
oriented  dialects  of  Ada  and  J73  for  simulation  and 
testing . 

}  Develop  J73  and  Ada  programming  aids  such  as 
linkers,  editors,  emulators,  auditors,  etc. 

f  Participate  in  the  Ada  development  process. 

2.3.6  Emulation  of  ECS^ 

An  emulation  is  a  simulation  of  a  weapon  system  computer  (target 
computer)  on  a  host  computer.  An  emulation  has  many  advantages  such 
as  the  ability  to  develop  software  prior  to  delivery  of  a  new  or  scarce 
target  computer,  to  record  intermediate  results,  and  to  debug  software 
(provisions  not  usually  contained  in  weapon-system  computers).  In 
aircrew  trainers,  an  emulation  of  the  weapon  system  computers  would 
allow  the  flight  software  to  be  loaded  with  minor  changes  (for  input-output) 
instead  of  having  to  be  recoded  for  a  large  host.  Emulations  executing 
on  scientific  hosts  typically  run  hundreds  of  times  slower  than  real  time; 
emulations  executing  on  special-purpose  emulations  run  5  to  10  times 
slower  than  real  time  and  require  that  "nanocode"  instructions  be  written 
that  emulate  the  microcode  in  the  target  computer.  New  parallel  com¬ 
puters  are  being  discussed  in  the  literature  that  will  execute  nanocode 
in  parallel  CPU's,  thus  permitting  real  time  emulation.  The  availability 
of  MIL-STD  1750A  chips  will  permit  trainers  to  be  constructed  with 
the  same  chips  as  are  used  in  weapon  systems  computers,  thereby 
allowing  the  flight  software  to  be  used  virtually  unchanged. 
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f  Concentrate  emulation  specialists  in  a  skill  center. 

I  Prepare  an  AFLC-wide  emulation  plan  to  avoid 
duplication  of  software  and  hardware  in  AFLC's. 

Relate  emulations  to  ISF's. 

t  Encourage  the  AFSC  aircrew  trainer  program  office 
to  develop  general-purpose  emulations  for  use  in 
several  trainers. 

^  Analyze  the  cost  of  retrofitting  trainers  with 
general-purpose  emulators  to  reduce  software 
rewriting. 

^  Develop  an  emulation  language  for  writing  microcode 
and  nanocode. 

2.3.7  Standardization^ 

AFLC  is  a  principal  beneficiary  of  standardization  which  can 
result  in  reduced  parts  inventory,  reduced  training,  fewer  software 
development  facilities,  less  prog  ram -unique  test  equipment,  less 
documentation,  and  higher  programmer  productivity.  To  enforce 
standardization,  AFLC  should  identify  the  cost  of  deviating  from 
standards  to  the  DSARC  during  the  earliest  phases  of  programs,  when 
changes  are  still  economically  possible.  Standardization  would  reduce 
AFLC  costs  in  the  following  areas  while  probably  having  little  impact 
on  weapon-system  performance. 

•  Computer  instruction  sets. 

•  Data  buses  for  interconnecting  distributed  computers. 

•  Standard  software  tools,  especially  for  J73  and  Ada. 
Examples  of  tools  are  emulators,  compilers,  linkers, 
and  editors. 

•  High  order  languages. 

•  Automatic  test  equipment,  especially  general-purpose 
shop  test  equipment. 

•  Mathematical  models  of  vehicles,  weapons,  environments, 
missions,  and  data  reduction  programs. 

•  Op  era  tor -interactive  systems. 
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*  Analyze  historical  data  to  prepare  cost  and  reliability 
w  models  of  hardware  and  software  maintenance.  Estimate 
the  cost  of  departure  from  standards. 

^  Identify  departures  from  standardization  for  each  pre- 
PMRT  program  and  estimate  the  cost  impact  on  AFLC 
at  the  DSARC  I  and  II. 

^  Establish  skill  centers  for  high  order  languages,  software 
tools,  mathematical  models,  and  operator-interactive 
software.  These  skill  centers  should  prepare  AFLC-wide 
plans,  and  should  work  with  AFSC  to  enforce  standards 
and  develop  AFLC  internal  standards  where  appropriate. 

2.3.8  Built-In  Test + 


The  use  of  built-in  test  (BIT)  circuitry  is  increasing  as  chip  costs 
fall.  BIT  detects  failures  and  permits  redundant  elements  to  be  simulated. 
BIT  is  designed  to  detect  certain  classes  of  failures.  The  trend  in 
electronics  design  is  toward  the  elimination  of  flight-line  testers  in 
favor  of  BIT  and  LRU -swapping.  The  trend  in  shop  equipment  is  toward 
general-purpose  computer -driven  testers  with  adapters  for  LRU's. 

LRU's  that  "check-out-ok"  or  whose  failure  cannot  be  duplicated  can 
be  tested  in  a  dynamic  ISF,  whose  primary  purpose  is  software 
development. 

RECOMMENDATIONS 

^  The  following  approach  is  recommended  to  determine 

costs  sensitivity  to  the  design  of  BIT. 

•  Analyze  the  mix  of  BIT  and  automatic  test 
equipment  to  determine  if  an  optimum  mix 
exists.  Determine  the  need  for  a  small 
number  of  standard  LRU  adapters. 

•  Determine  the  economical  level  of  BIT  in  each 
type  of  LRU,  including  AFSC  and  AFLC  costs 
and  USAF  mission  costs  (e.g.,  destroyed 
aircraft  and  a  larger  fleet  to  complete 
planned  missions). 

•  Ensure  that  fault-tolerant  ECS  include  the  means 
to  induce  faults  and  verify  proper  operation  of  BIT. 


*  Detailed  discussion  in  Section  9,  Volume  VIII. 
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2.3.9  Operator-Computsr  Interaction 

The  hundreds  of  computer  terminals  within  AFLC  have  a  variety 
of  functions  including 

•  T  est  proces sing , 

•  Inventory  control, 

•  Computing, 

•  Integration  Support  Facilities, 

•  Trainers, 

•  Test  sets, 

•  Management  information  systems,  and 

•  Computer  programming. 

These  terminals  are  made  by  many  different  manufacturers  and 
contain  varying  degrees  of  intelligence,  different  operator-input  devices, 
and  different  driver  software.  The  method  of  changing  the  computer 
program  to  change  formats  and  the  interactive  procedure  by  which  the 
user  calls  formats  differ  radically.  There  is  no  standardization  of  soft¬ 
ware  although  several  low-level  standards  are  in  development.  Equip¬ 
ment  and  software  exhibit  rapid  obsolescence  and  are  not,  in  general, 
interchangeable  among  manufacturers.  Software  packages  are  sold  by 
many  manufacturers  for  word  processing,  tabular  displays,  and 
pictorial  displays. 

RECOMMENDATIONS 

t  In  this  fluid  marketplace,  standardization  is  not  currently 
recommended.  Instead,  the  follow  approach  warrants 
consideration. 

•  AFLC  should  undertake  a  survey  of  operator - 
interactive  needs:  How  many  users  are  there 
and  what  do  they  do?  How  many  must  use,  (and 
therefore  learn)  systems  of  more  than  one 
manufacturer?  How  many  terminals  of  each 
type  are  in  inventory? 
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•  AFLC  should  establish  a  skill  center  of  interactive- 
software  specialists  who  can  write  drivers  and 
applications -independent  graphics.  They  would 

be  in  demand  to  augment  purchased  software 
packages  and  to  interface  terminals  and  computers 
that  are  otherwise  incompatible.  They  would 
also  have  a  test  bed  for  development  of  inter¬ 
active  software, 

•  Adapt  standards  as  they  are  created.  A  low-level 
ANSI  core  graphics  standard  now  exists  and  the 
ACM-Siggraph  standard  is  being  prepared. 

AFLC  may  wish  to  participate  in  the  development 
of  newer  standards  if  the  survey  shows  that  its 
needs  are  unique. 


2.3.  10  Management-Oriented  Initiatives 

Management-oriented  initiatives  can  significantly  dilute  the 
economic  impact  of  technological  advances  and  thus  greatly  assist  in 
AFLC's  economic  adaptation  to  these  advances. 

RECOMMENDATIONS 

t  AFLC  should  increase  the  productivity  of  its  technical 
staff  by  adopting  software  and  hardware  standards  and 
by  installing  an  intercenter  network. 

^  AFLC  should  identify  AFSC  -proposed  deviations  from 
standards  starting  at  DSARC-1  and  should  identify  the 
projected  costs  to  AFLC  of  those  deviations.  AFLC 
should  spend  2  to  5  percent  of  support  costs  analyzing 
designs  and  should  propose  preferred  designs  to 
AFSC  and  DSARC . 

t  In  order  to  make  better  use  of  increasingly  scarce 
specialists,  AFLC  should  establish  centralized  skill 
centers  for  ISF  simulations  in  support  of  distributed 
avionics  networks,  high  order  languages,  software 
tools,  mathematical  models,  operator -interactive 
software,  management  of  the  intercenter  network, 
and  the  standardization  effort.  AFLC  should  invest 
2  percent  of  support  costs  planning  these  systems 
and  facilities  on  an  AFLC -wide  basis. 

t  AFLC  should  analyze  and  publish  historical  data  on 
the  cost  of  maintaining  and  supporting  ECS  hardware 
and  software  and  on  failure  rates. 
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2.4  NATIONAL  SOFTWARE  WORKS  INVESTIGATION 


A  separate  study  task^  was  an  investigation  and  assessment  of 
the  current  and  future  applicability  of  the  National  Software  Works  (NSW) 
to  AFLC  software  support  requirements  for  ECS.  Primarily,  these 
results  were  obtained  by  contrasting  current  NSW  status  and  available 
tools  with  current  AFLC  ECS  software  support  requirements.  The 
assessment  of  future  applicability  was  based  upon  a  comparison  of 
NSW  status  and  tools  with  a  series  of  capabilities  postulated  to  meet 
future  AFLC  requirements.  Finally,  the  assessment  encompassed  a 
consideration  of  networking  as  it  would  generally  apply  to  future  AFLC 
needs. 

RECOMMENDATIONS 

9  AFLC  should  not  depend  upon  the  NSW  as  a  near-term 
capability.  AFLC  should  depend  upon  NSW  as  a  future 
capability  only  if  the  NSW  is  significantly  upgraded. 

f  Networking  is  definitely  applicable  to  AFLC  ECS 
support  requirements  and  acquisition  planning  for 
an  applicable  network  should  be  initiated. 
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3.  LONG  RANGE  PLAN  (OUTLINE) 


The  long  range  plan  will  describe  the  recommended  additional 
administrative  and  programmatic  initiatives  to  be  taken  by  HQ  AFLC 
to  achieve  a  mission  effective  Embedded  Computer  System  (ECS)  support 
posture  by  1990.  This  outline  discusses  the  structure  and  content  and 
the  approach  to  development  of  the  long  range  plan. 

3.  1  BACKGROUND 

Embedded  computer  systems  are  defined  as  computer  systems 
that  are  an  integral  part  of  a  larger  electronic  or  electromechanical 
system.  The  specific  categories  of  ECS  included  in  the  plan  are 

•  Aircrew  Training  Devices  (ATD), 

•  Automatic  Test  Equipment  (ATE), 

•  Communications-Electronics  (C-E), 

•  Electronic  Warfare  (EW),  and 

•  Operational  Flight  Programs  (OFP). 

Support  concepts  for  the  five  categories  of  ECS  have  evolved  over 
a  period  of  time.  This  is  also  true  for  the  definition  of  the  ECS  cate¬ 
gories  themselves.  Beginning  with  Project  Pacer  Flash,  three  cate¬ 
gories  were  defined  (OFP,  ATE,  and  ATD)  with  two  others  (EW  and 
C-E)  added  later.  Although  the  categories  and  concepts  have  been 
evolving  for  some  time,  documentation  of  the  categories  and  support 
concepts,  at  least  in  part,  occurred  very  recently.  Current  documents 
establish:  (1)  an  Avionics  Integration  Support  Facility  (AISF)/Integration 
Support  Facility  (ISF)  concept  for  ECS  categories  OFP,  EW,  and  C-E 
(2)  a  Software  Support  Center  (SSC)  concept  for  ECS  category  ATE, 
and  (3)  the  Development  Engineering  Prototype  Site  (DEPS)  concept  for 
ECS  category  ATD. 

A  clearer  definition  of  support  requirements  for  the  various  ECS 
categories  has  also  emerged  along  with  the  firming  up  of  the  category 
and  concept  definitions.  The  common  support  requirements  that  apply 
across  all  five  ECS  categories  are  described  in  the  requirements  base¬ 
line  volumes  as  a  generic  ECS  change  process.  This  set  of  generic 


requirements,  when  combined  with  category  peculiar  requirements  such 
as  rapid  reprogramming  for  EW,  or  nuclear  weapons  in  the  case  of  OFP, 
comprise  the  ECS  support  requirements  for  a  given  ECS  category.  The 
change  process  in  abbreviated  form,  which  is  common  to  all  ECS  cate¬ 
gories  in  the  post-PMRT  time  period  is  described  in  Table  3-1. 

In  the  past,  support  objectives  for  the  various  ECS  categories  have 
been  stated  at  a  high  level  with  implementation  mostly  on  a  case  by  case 
basis  even  within  individual  categories.  This  was  done,  at  least  in  part, 
to  validate  several  support  approaches  but  has  resulted  in  the  current 
support  posture  with  various  approaches  to  ECS  support  and  has  spawned 
a  number  of  support  problems  which  are  discussed  in  the  Phase  II 
report.  An  approach  to  the  resolution  of  these  problems,  many  of 
which  are  long  standing,  is  dependent  upon  clearly  stated  support  objec¬ 
tives  and  implementation  of  specific  initiatives. 

3.  1.  1  Source  Material  for  the  Long  Range  Plan 

The  Phase  II  report  describes  the  current  support  posture  and 
provides  assessments  of  the  deficiencies/problems  encountered  in  the 
support  of  the  five  categories  of  embedded  computer  systems.  In  addition, 
it  contains  a  forecast  of  the  impact  of  future  technology  with  regard  to 
ECS  support  and  assesses  the  applicability  of  the  National  Software  Works 
(NSW)  to  near-term  ECS  support  requirements.  Based  on  the  information 
documented  in  the  Phase  II  report  and  additional  data  generated  in 
Phase  III,  the  long  range  plan  will  describe  a  recommended  course  of 
action  to  attain  the  future  ECS  support  posture. 

3.1.2  Long  Range  Plan  Development  Tasks 

The  initial  task  in  developing  the  long  range  plan  during  Phase  III 
is  to  postulate/ project  a  future  ECS  support  environment.  This  activity 
is  shown  as  Step  1  in  Figure  3-1.  This  task,  which  requires  close 
coordination  with  AFLC/LO,  involves  the  synthesis  of  stated  or  docu¬ 
mented,  as  well  as  perceived,  ECS  support  needs  into  an  objective  or 
target  ECS  future  support  posture.  The  remaining  task  shown  as 
Step  2  in  the  figure,  is  to  determine  any  additional  initiatives  to  achieve 
the  future  support  posture  and  to  categorize  them  along  with  the  ECS 
support  initiatives  described  in  the  Phase  II  reports  into  administrative 
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Table  3-1.  Generic  ECS  Support  Requirements 


ECS  Change 

•  Receive  and  process  request 

•  Preliminary  analysis  and  problem/deficiency 
definition 

•  Preliminary  resource  allocation  and  scheduling 
Change  Analysis  and  Specification 

•  Feasibility 

•  Requirements  decomposition/definition 

•  Preliminary  design 

•  Detailed  design 

•  Generate  change  proposal 


Engineering  Development  and  Unit  Test 

•  Develop  the  change 

•  Perform  engineering  tests 


System  Integration  and  Test 

•  Test  ECS  system  performance 

•  Test  weapon  system  performance 

•  Produce  test  reports 

Change  Documentation 

•  Document  ECS  change 

•  Update  ECS  baseline 

•  Configuration  control 

Certification  and  Distribution 

•  Certify  documentation 

•  Distribute  revised  ECS  data 

•  Provide  installation  procedures/ instructions 
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Figure  3-1.  Road  to  ECS  Support  in  the  1980 


and  programmatic  actions.  The  long  range  plan  will  contain  an  outline 
of  the  administrative  actions  which  are  within  the  government  domain 
and  recommended  for  near-term  implementation.  The  plan  will  also 
contain  the  time  phased  implementation  schedules  for  the  recommended 
programmatic  actions.  This  latter  activity  is  currently  envisioned  as  a 
major  portion  of  the  study  effort  during  Phase  III. 

3.  1.  3  Scope  of  the  Long  Range  Plan 

The  long  range  plan  focuses  on  weapon  and  support  systems  con¬ 
taining  embedded  computer  systems  and  emphasizes  the  computer  pro¬ 
gram  (software)  aspects  of  ECS  support.  The  plan  addresses  the  manage¬ 
ment  and  technical  activities  necessary  by  HQ  AFLC  for  attainment  of  a 
mission  responsive  support  posture  for  each  of  the  five  categories  of 
ECS  during  the  1980' s. 

The  long  range  plan  will  conform  with  the  current  AFLC  manage¬ 
ment  concept  of  centralized  control  and  decentralized  implementation 
of  the  activities  required  for  support  of  the  various  categories  of  ECS. 
Major  emphasis  in  the  plan  is  on  the  support  requirements,  concepts, 
organization  and  resources  (people  and  tools)  necessary  to  achieve  a 
recommended  future  support  posture  for  a  rapidly  increasing  ECS  support 
role.  The  plan  focuses  on  the  ECS  support  requirements  that  are  appli¬ 
cable  or  common  to  all  five  ECS  categories,  thereby  increasing  the 
command -wide  benefits  of  implementation  of  any  given  recommended 
activity.  Conceptually  the  plan  will  consider  extensive  use  of  both 
internal  and  external  networking  to  the  ECS  support  facility  locations.  In 
addition,  a  major  theme  in  the  plan  is  standarization  of  tools,  equipment, 
and  procedures. 

3.  2  LONG  RANGE  PLAN  DEVELOPMENT  APPROACH 

The  first  major  task  in  developing  the  long  range  plan  is  to  postulate/ 
project  a  future  ECS  support  environment  that  satisfies:  (1)  the  projected 
requirements  contained  in  the  current  Statement  of  Need/Mission  Element 
Need  Analysis  (SON/MENA),  (2)  other  requirements  not  specified  in  the 
SON/MENA  that  are  discussed  in  the  Phase  II  recommendations/alter¬ 
natives  and  in  the  technology  forecast,  (3)  the  common  and  unique  ECS 
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category  support  requirements  documented  in  the  baseline  reports,  and 
(4)  the  current  and  projected  ECS  category  support  concepts.  This 
postulated/projected  ECS  support  environment  will  be  coordinated  with 
HQ  AFLC/ LO  and  stated  in  the  form  of  objectives/goals .  The  other 
major  task  to  be  accomplished  during  Phase  III  is  to  determine  the 
actions  necessary  to  achieve  these  objectives/goals.  These  actions 
consist  primarily  of:  (1)  initiatives  to  correct  deficiencies  in  the  current 
support  posture  and  (Z)  new  initiatives  to  satisfy  the  future  objectives/ 
goals  and  achieve  the  future  support  posture.  The  overall  process  is 
shown  in  Figure  3-2. 

The  currently  envisioned  method  for  presenting  the  implementing 
steps  to  attain  the  future  ECS  support  posture  is  to  group,  when  possible, 
the  actions /initiatives  into  either  administrative  or  programmatic  actions. 
The  methodology  also  groups  and  addresses  the  selected  initiatives  in 
three  basic  time  periods.  The  time  periods  under  consideration  are 
the  near-term  (1-2  years),  mid-term  (1-5  years)  and  long-term  (1-10 
years).  The  remaining  task  is  to  outline  the  administrative  actions 
necessary  for  near-term  implementation  to  correct  deficiencies  and 
develop  the  time-phased  implementation  schedules  for  the  programmatic 
actions. 

An  example  of  an  activity  which  lends  itself  to  administrative/ 
directive  solution  and  is  a  candidate  for  near-term  implementation  is 
presented  in  summary  form  in  Table  3-2,  This  particular  activity  is  a 
sensitive  and  volatile  ECS  support  issue  of  long  standing  that  is  clearly 
within  the  government  policy  and  guidance  domain.  Consequently  it 
would  be  presented  in  outline  form  in  the  long  range  plan. 

An  example  of  an  initiative  that  involves  adminstrative  action  to 
implement  but  is  primarily  programmatic  in  nature,  a  candidate  for 
near  term  implementation,  and  is  considered  appropriate  for  more 
definitive  implementation  detail  is  configuration  management.  Table 
3-3  briefly  summarises  this  candidate  initiative. 
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Long  Range  Plan  Development  Approach 


Table  3-2.  Example  Action/Initiative 


Item:  Funding 

Objective:  Establish/ cla rify  policy  and  guidance  for 

support  of  Embedded  Computer  Resources. 

Recommendation: 

Establish  definitive  funding  lines  within  AFR  800-14 
and  program  management  directives  to  route  pre- 
PMRT  funds  to  AFLC  agencies  to  enable  adequate 
participation  in  the  acquisition  process,  acquire 
appropriate  O&S  support  facilities,  and  perform/ 
participate  in  IV**V  activities. 
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3.  3  ECS  SUPPORT  ORGANIZATION  AND  RESOURCES 

The  organizational  responsibilities  and  interfaces  associated  with 
the  programmatic  initiatives  to  be  contained  in  the  long  range  plan  will 
be  presented  in  a  life  cycle  context  and  within  the  framework  shown  in 
Figure  3-3.  The  currently  envisioned  focus  for  the  top  level  responsi¬ 
bilities  and  external  interfaces  is  as  follows:  HQ  AFLC  has  responsi¬ 
bility  for  ECS  support  policy  and  guidance  and  primarily  interfaces  with 
other  MAJCOMS.  The  Acquisition  Logistics  Division  has  responsibility 
for  ECS  support  system  acquisition  and  primarily  interfaces  with  the 
Air  Force  System  Command' s  Product  Divisions.  The  Air  Logistics 
Centers  and  the  Aerospace  Guidance  and  Meteorology  Center  have  respon¬ 
sibility  for  ECS  support  system  operation  and  primarily  interface  with  the 
weapon  system  users. 

The  long  range  plan  also  identifies  the  resources  such  as  person¬ 
nel,  equipment  and  facilities  that  are  related  to  the  recommended  pro¬ 
grammatic  actions.  In  addition  is  discusses:  (1)  the  scope  of  the  manage¬ 
ment  and  technical  skills  and  training  programs  necessary  to  acquire  the 
human  resources  for  effective  ECS  support  during  the  1980' s  and  (2)  the 
required  equipment  (tools)  and  facilities  (brick  and  mortar)  in  terms  of 
the  federal  budget  cycle  and  military  construction  programs. 
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Figure  3-3.  ECS  Acquisition  and  Support  Interfaces 


